Looks like wasm builds don't like using core::panic::catch_unwind. Opinions on if I should disable the test that uses that in wasm builds? And if so, how? Or create 11 separate #[should_panic] tests?

The main reason that I had in mind for using an Iterator, rather than a Vec, for the weights is that it doesn't put any constraints on the storage format. For example:

let my_items = vec![("foo", 10), ("bar", 3), ("baz", 1)];
let weights = my_items.iter().map(|x| x.1);
println!("{:?}", rng.choose_weighted(my_items.iter(), weights));

Or

let my_items = get_vec_of_structs();
let weights = my_items.iter().map(|x| x.get_weight());
println!("{:?}", rng.choose_weighted(my_items.iter(), weights));

An alternative way to accomplish this goal would be to do something like:

    fn choose_weighted<Iter, F, Weight>(&mut self,
                                        items: Iter,
                                        f: F) -> Option<Iter::Item>
        where Iter: Iterator + Clone,
              F: FnMut(&Iter::Item) -> Weight,
              Weight: SampleUniform +
                      Default +
                      core::ops::Add<IterWeights::Item, Output=IterWeights::Item> +
                      core::cmp::PartialOrd<IterWeights::Item> +
                      Clone

This would work as well, but means that if the weights and items are stored in different vectors, then the caller will have to .zip() the lists together and will get back a tuple containing the chosen item, rather than the item itself.

I've rebased this on top of #483 and moved the choose_weighted methods off of Rng and instead live as functions inside the seq module.

This leaves it with a signature like this:

pub fn choose_weighted<R, IterItems, IterWeights>(rng: &mut R,
                                                  items: IterItems,
                                                  weights: IterWeights) -> Option<IterItems::Item>
    where R: Rng + ?Sized,
          IterItems: Iterator,
          IterWeights: Iterator + Clone,
          IterWeights::Item: SampleUniform + ...

Same thing for choose_weighted_with_total, just with an extra total_weight argument.

One alternative approach would be only let this function deal with the weights iterator. And instead of returning an IterItems::Item, return the index of the selected weight. Then it's up to the caller of using that index to grab an item from a slice (vec[index]) or from an iterator (iter.nth(index)).

This would leave us with a singature like:

pub trait IteratorRandom: Iterator + Sized {
    ...

    fn choose_index_weighted<R>(mut self,
                                rng: &mut R) -> Option<usize>
        where R: Rng + ?Sized,
              Self: Clone,
              Self::Item: SampleUniform + ...
    {
        ...

There's a few of upsides to this.

• We don't have to have a "global" function in the seq module, but can instead stick this function together with the other choose, choose_multiple etc.
• The signature is obviously simpler.
• It's a lower-level primitive which can be useful if the caller want to remember the index for longer than they can hold on to a returned reference.
• Once we implement a replacement for WeightedChoice, i.e. a Distribution which can return multiple items from a weighted distribution, the Distribution object will work well borrow checker. It'll own all the calculated cumulative weights and return usizes. It will not need to hold references to external items.

But also a few downsides:

• This doesn't provide as much functionality. I.e. we have SliceRandom::choose even though we have Rng::gen_range exists. Though if really needed we could easily add a function with the old signature which wraps the new one. That could easily be done later.
• The returned type is different from other choose methods since it returns an index rather than an item.
• The caller has to potentially deal with unwrapping Options twice. Once from this function and once from Iterator::nth.

Ultimately I'm leaning towards this new way being a better solution though.

Some code differences:
Old:

// tuples or structs
let items = [('a', 2), ('b', 1), ('c', 1)];
let weights = items.iter().map(|&(_, w)| w);
let item = choose_weighted(&mut rng, items.iter(), weights).unwrap();

// separate arrays
let items = ['a', 'b', 'c'];
let weights = [2,   1,   1];
let item = choose_weighted(&mut rng, items.iter(), weights.iter()).unwrap();

// iterators
let items = get_items();
let weights = get_item_weights();
let item = choose_weighted(&mut rng, items, weights).unwrap();

New:

// tuples or structs
let items = [('a', 2), ('b', 1), ('c', 1)];
let item = items.iter().map(|&(_, w)| w)
    .choose_index_weighted(&mut rng)
    .map(|pos| items[pos]).unwrap();

// separate arrays
let items = ['a', 'b', 'c'];
let weights = [2,   1,   1];
let item = weights.iter()
    .choose_index_weighted(&mut rng)
    .map(|pos| items[pos]).unwrap();

// iterators
let items = get_items();
let weights = get_item_weights();
let item = weights
    .choose_index_weighted(&mut rng)
    .and_then(|pos| items.nth(pos)).unwrap();

A choose_index_weighted function seems like a good idea. How about also having a function like this?

fn choose_weighted<W, WF>(&self, weights: WF) -> T
  where WF: Fn(&T, usize) -> W,
  W: /* weight type requirements */

This may be usable like so:

let items = [('a', 2), ('b', 1), ('c', 1)];
let item = items.choose_weighted(|x, _| x.1).unwrap().0;

// separate arrays
let items = ['a', 'b', 'c'];
let weights = [2,   1,   1];
let item = items.choose_weighted(|_, i| weights[i]).unwrap();

I'm not sure if providing both an index and reference to the item in this function is overkill? I'm also not sure how well it optimises.

I'll create separate PRs for the tests and for choose_weighted. The rest of these changes are covered by #483